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y^7 r1 tTT T» OF TP* 1 INVF.NTIOM 

* V This invention relates to computer graphics, and more particularly, to 

• /« ~,w, nr ,"\ a texture map from a source texture 
5 techniques for metamorphosing ("morphing ) a texture m p 

to a target texture. 

n mgraphics.metamorphosis.ormorphing.istheprocessofgraduaUychanging 
% source object through intermediate objects into a target object. For exampie, a 
10 " person's face can be morphed into another person's face, an animal can be 

€rphedi,oahuman,etc. Morphing can create string special effects, and has 
P nulrous apphcations - from mode.ing, computer simuiation and vtdeo games 
E! g e„erationofanimat ion sequences for the movie and advertising mdusmes. 
: 8 p^advancementsinBDmorphinghavetendedtoconcentrateondevelopmg 

J a , go rithmsfor morphing geometry between source and target objects However, 
" modem 3D graphics commonly uses texture mapping to -e 3D ob.ee sm« 
interesting and apparently more complex. Generally, texture mappmg m ^ 
taking a 2D image (e.g., a photographic or other digitized p.cture) and p.acng 
onto a 3D surface. As one examp.e, a bricx wall can be imaged by mapp-ng a 
20 bric.-and-mortar texture onto a simp, — iar surface of a 3D "wa o^ 
Imag es of foliage, clouds, and a variety of other complex .mages can al, be created 
using such texture mapping techniques. 

When attempting to morph a textured 3D image, one must morph the texture 
as well as the geometry. Texture maps can be iarge, and each texel in the map 
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should be morphed to provide a range of interpolated texture values between 
source and target textures. Such texture morphing therefore tends to be 
computationally expensive - effectively preventing resource-constrained real-time 
graphics systems such as home video game systems and personal computer 
5 graphics cards from providing real-time texture morphing functionality. What is 
needed is a texture morphing procedure that is fast and efficient enough to be 
performed in real-time within limited resource environments so that texture 
morphing can be performed "on the fly" in a limited resource graphics system. 
The present invention provides a solution to this problem by providing a fast, 
10 C3 real-time texture morphing algorithm that is both fast and efficient. The preferred 
is embodiment of the invention provides a number of efficiencies to simplify and 
15 reduce the computations required within a texture morphing/blending process, 
m such techniques including off-line texel component decomposition; incremental 
" interpolation; frame counters; interlace morphing; and background low-priority 
15 tl threading. These techniques can be used individually and/or in combination to 
IS provide morphing procedures fast enough for real-time computer animation and 
C3 simulation and video games. 

In accordance 4th one aspect of the present invention, incremental 
'^ymterpolation techniques are used to reduce repetitive and heavy floating point 
number calculations/conversions associated with the typical texel 
blending/morphing process. The preferred embodiment computes an incremental 
morph parameter t for eaVh texel component based on previous value and change 
rate (e.g., image frame ratV and the time duration of the morphing process). Initial 
and incremental morph parameter values can be computed in advance for each 
25 texel component during a preliminary morph preparation background process. 
Then, during a subsequent re\l-time morphing process, these initial and 
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incremental parameter values areVpplied incrementally to morph the texel 
components toward target texel component values. 

To save floating-to-fixed point conversion time, the preferred embodiment 
uses integer addition to apply the incremental morph parameter values to the texel 
5 component values. However, to preserve accuracy, incremental and new values 
should be floating point numbers. The preferred embodiment resolves this 
inconsistency by using a frame counter concept. The morph parameter 
preparation process determines, for each texel component value, how many image 
frames it will take for a fractional portion of the incremental parameter value to 
1QJ change the integer portion of the texel component value. The preferred 
=E embodiment carefully chooses the resulting frame counter values to prevent over- 
l3 runs, and uses them to specify when additional integer correction factors should be 
m applied during the incremental interpolation process. To avoid image artifacts due 
V to mismatch between the morphed texel component values and the actual target 
ill texel values, the preferred embodiment "snaps" the texel values to the precise 
e| (floating point) target values during the last morph iteration. 
g j In accordance with another aspect of the invention, incremental interpolation 
^j^ycan be appliedeach frame time or other morphing period to less than all of texels 

/ being morphedA For example, some texels can be incrementally interpolated 
20 during a particular frame, other texels can be incrementally interpolated during a 
subsequent framei etc . — so that all texels are incrementally interpolated across a 
certain (preferably^mall) number of frames without requiring each texel to be 
interpolated every frame. Such interlacing of incremental interpolation can 
significantly reduce Computational load without introducing significant image 
25 artifacts. \ 
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In accordance with yet another aspect of the invention, the texture buffer data 
' structure is initially decomposed off-line to reduce the number of real-time 
operations required to separate and manipulate texel component data for 
morphing. The preferred embodiment decomposes the standard texture map into 
5 separate arrays for each of the colors (RGB) and for alpha (transparency). The 
resulting component arrays (which may be 8-bit integer arrays, for example) can 
be manipulated directly by real-time software without additional masking/data 
extraction overhead. 

^ ~~1 One significant and advantageous application of the present invention is to 
allow dynamic generation of a virtually infinite number of video game characters 

% i and other textared\objects "on the fly" using morphing procedures within home 
video game systems, personal computer graphics cards, and other inexpensive 

I % graphics systems. iAis possible to pre-construct a number of objects with certain 

w geometry and textures as primary sources and targets (" morph terminals"), and 
ihf then use the texture morphing features provided by this invention to smoothly 
transform textures in real time between such objects to generate a sequence of 

52 continuous intermediate objects along morphing paths between the morph 
terminals. Since the preferred embodiment stores each set of intermediate 
morphed texture values as aVexture map, any such intermediate texture map can 
20 be used as a source texture m^p for a further texture morphing operation along the 
same or different morph path. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features and advantages provided by the present invention 
will be better and more completely understood by referring to the following 
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detailed description of preferred embodiments in conjunction with the drawings of 
which: 

Figure 1 shows an overall example 3D graphics system; 

Figure 2 shows an example virtual object morphing space; 

Figure 3 is a flowchart of an example overall texture morphing process 
provided by the present invention; 

Figure 3A shows an example graphics system storage device that stores 
information to control the Figure 1 graphics system to perform the steps shown in 
Figure 3; 

Figure 4 shows example off-line decomposition of a texture map into 
separate component arrays; 

Figures 5 & 5A-5D illustrate an example incremental morphing process; 
Figure 6 shows an example interlacing example; and 

Figure 7 is a flowchart of example steps the preferred embodiment performs 
to provide incremental interlaced texture morphing. 

DETAILED DESCRIPTION OF 
PRESENTLY PREFERRED EXAMPLE EMBODIMENTS 

Figure 1 shows an example real time 3-D computer graphics display system 
50 that may be used to provide realistic interactive real time 3D morphing in 
accordance with the present invention. The Figure 1 example system 50 includes 
a NINTENDO 64® 3-D video game console 52 and associated hand controllers 
54a, 54b. A cartridge 56, optical disk or other storage medium storing a software 
animation (video game) program is operatively connected to console 52. The 
console 52 is connected to a display device 58 such as a conventional home color 
television set or computer monitor. Console 52 includes a 3D graphics engine that 




can render 3D animation on display 58 in real time response to user manipulation 
of controllers 54a, 54b. The software within cartridge 56 controls console 52 to 
display a sequence of animated video frames on display 58. Human players may 
operate hand controllers 54a, 54b to cause, under control of software within game 
5 cartridge 56, game characters to morph interactively in real time. 

Figure 2 shows an example of how intermediate morph objects can be 
dynamically created between three morph terminals 10, 12, 14 using the Figure 1 
system. The objects in circles (obj 1, obj2 and obj3) are intermediate morph 
objects. In this particular Figure 2 example, morphing terminals 10, 12 and 14 
10 comprise a dog, a human and a vehicle, respectively. In this example, any 
It morphing terminal 10, 12, 14 can be morphed into any other morphing terminal 
along morphing paths 16. For example, dog morph terminal 10 can be morphed 
jfjj into human morph terminal 12 (or vice versa) along morphing path 16a; human 
m morph terminal 12 can be morphed into vehicle morph terminal 14 (or vice versa) 
llh along morph path 16b; and dog morph terminal 10 can be morphed into vehicle 
jf ij morph terminal 14 (or vice versa) along morph path 16c. 

J 3 In this example, the morph procedure can be stopped at any point during the 

" procedure (not necessarily at the source or the target), and the intermediate object 
at that point can be used as a new game character with an "in-between" shape and 
20 color. This new object (for example, object "Obj 1 11 — a morph hybrid of a dog and 
a human) could be used as a source for yet another morph procedure to further 
morph the object into a further morph "Obj2" and so on. 

More generally, the morph terminals 10, 12, 14 define a virtual object space 
VOS. Any point inside the space VOS represents an intermediate object which 
25 could be rendered as any other pre-constructed object(s) in the simulations. Such 
an ability has the potential of stunning game players by its versatility and 
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" unpredictability - producing hit video game titles that are interesting and 
enjoyable to play. 

Texture Morphing 

Those skilled in the art understand that there already exist a number of 
5 efficient algorithms for morphing geometrical data of 3D objects. See, for 

example, Chen et al, "Interactive Shape Metamorphosis", 1995 Symposium on 
Interactive ID Graphics pp. 43-44 (ACM SIGGRAPH April 1995). However, 
when morphing between the source and target 3D objects, not only the geometry 
(vertices and polygons) of the object, but also the color and texture of the object 
10 O must be transformed from "source form" to "target form". Texture morphing has, 
-« in the past, typically been performed using a computationally intensive brute-force 
W heuristic color blending approach. 

CO A Heuristic Approach 

f ? For example, assume a conventional RGB A 32-bit texture map format and 
151k 1 further assume that the current morph source, target and intermediate textures are 

f J stored in array sourceTexture[], targetTexture[] and mediateBuffer[] respectively. 
The brute-force heuristic solution for blending (interpolating) texture components 
can be described by the following pseudo-code for performing a general floating- 
point interpolation function to interpolate between source and target texture maps: 

20 for(each texel in each texture tile) { 

//decompose source and target texels into R,G,B,A components; 

sourceRed = (sourceTexturefkJ & OxjfOOOOOO) » 24; 

sourceGrn = (sourceTexturefkJ & OxOOffOOOO) » 16; 

sourceBlu = (sourceTexturefkJ & OxOOOOffOO) » 8; 
•25 sourceAlp = (sourceTexturefkJ & OxOOOOOOff); 

targe tRed = (targetTexturefkJ & OxjfOOOOOO) » 24; 

targetGrn = (targetTexturefkJ & OxOOffOOOO) » 16; 
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targetBlu = (targetTexturefkJ & OxOOOOffOO) » 8; 
targetAlp = (targetTexturefkJ & OxOOOOOOff): 
// interpolate the color components 
newRed = (1-t) * sourceRed + t * targetRed; 
5 newGrn = (1-t) * sourceGrn + t * targetGrn; 

newBlu = (1-t) * sourceBlu + t * targetBlu; 
newAlp = (1-t) * sourceAlp + t * targetAlp; 
//Assemble the new texel from new components; 

mediateBufferfkJ = (newRed< <24) \ (newGrn< <16)\ (newBlu< <8)\newAlp; 

10 ; 

where 0.0 <= t <= 1.0 is the morph parameter (i.e., the position of the current 
morph along a morph path 16). 

Those skilled in the art will understand that such a brute-force heuristic 
15 SI approach is straightforward to implement but very computationally expensive -- 
°a and is therefore not really feasible for real-time interactive limited resource 
m computation environments such as 3D home video game systems. 

New Texture Mo^hing Process Provided by the Present Invention 

Figure 3 is aNflowchart of an overall process provided by a presently 
20p» preferred example process 100 of the invention. Process 100 is divided into two 
ES overall stages: an authoring^tage 102, and a run-time stage 104. 

During authoring stage 102, process 100 performs a step 106 that 
decomposes texel color information to be morphed into separate RGBA 
component arrays. These separate arrays can be handled at run-time more 
25 efficiently than could a typical unified RGBA texel array. In the preferred 

embodiment, the separate RGBA arrays are stored in cartridge 56, from which 
they can be efficiently read out and copied into the read/write memory of system 
52 for efficient manipulation. 
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During run-time stage 104 (which may, in the preferred embodiment, be 
performed in real time response to interactive inputs provided by user-operated 
controls 54), the preferred embodiment defines initial and incremental morphing 
parameters for the texels to be morphed (block 1 08). This morphing parameter 
5 definition step may be performed once per source/target change as a background 
task some time in advance of when morphing must begin (block 108). Then, 
during a run-time morphing step (block 1 10), the preferred embodiment applies 
the incremental morphing parameters to the RGBA texel arrays using integer 
addition to provide incremental interpolation in an interlaced fashion -- avoiding 

10 under-runs by "snapping" the texel values to exact target values when (if) the 

~ j morph target is reached. 

o Figure 3A shows the Figure 1 cartridge 56 or other storage medium storing 

r jj software code 56a (e.g., in a read only memory) controlling system 50 to perform 
!□ the Figure 3 texture morphing process. In this example, storage device 56 stores, 
|| among other things: 

h • conventional texture mapping software instructions 56- 1 , 

p • instructions for implementing texel morph precompute step 1 08, 

• instructions for implementing texel morph compute step 110; 

• separate texture component arrays as shown in Figure 4; 

20 • conventional instructions for controlling system 50 to interactively 

respond to user inputs via controllers 54; and 

• conventional instructions for controlling system 50 to display 3D 
textured objects. 
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Off-line color decomposition: 

Figure 4 details an example off-line color decomposition step 106. To 
eliminate* texel decomposition and new texel assembly at run-time, the preferred 
embodiment reserves and loads one 32-bit texture map block in the static display 

5 list (i.e. textureBuffer[]) for the intermediate object. Instead of using one 32-bit 
array 120 (a conventional form for texture maps), the preferred embodiment 
decomposes the RGBA texels components of texture map 120 off-line and uses 
resulting separate texel component arrays (e.g., 8-bit arrays 122R, 122G, 122B 
and 122 A for the red, green, blue and alpha texel components, respectively) to 
1(W store the texel components. As compared to the heuristic approach discussed 

« above, the code that extracts the individual RGBA values from the 32-bit texel 

IJ map can be eliminated, leaving the only the code for color interpolation left in the 

m "for" loop as: 

3_ for (each texel in each texture tile) { 

IS* unsigned char * texel = &textureBuffer[k]; 

j| texelfREDJ = (1-t) * sourceRedfk] + t * targetRedfkJ; 

E| texelfGRNJ = (1-t) * sourceGrnfkJ + / * targetGrnfkJ; 

B texelfBLUJ = (1-t) * sourceBlu[k] + t * targetBlu[k] ; 

texel[ALP] = (1-t) * sourceAlpfk] + / * targetAlpfkJ; 

20 } 

However, the preferred embodiment does not use this form of interpolation, 
but instead uses a faster incremental interpolation process discussed below. 

Incremental interpolation: 

25 To reduce repetitive and heavy floating point number calculations, consider 

how the red component is computed (interpolated) for a particular texel: 
r = (1-t) * SR + t * TR (E.l) 



10 



where r is the new red component, SR and TR are source and target red 
components respectively, and t is a real number that changes along the morphing 
procedure from 0.0 through 1.0. If the frame rate (FR) is a constant (say, 30 
frames per second), and the number of seconds (S) within which the morphing has 
5 to finish is given, then the rate of change of t, represented by At, is obtained by 
At = 1 / (FR * S) (E.2) 
In other words, the value of t can be pre-computed incrementally based on its 
value in the previous time slot and its change rate, i.e. 

t'=t + At. (E.3) 
1(X3 Inserting (E.3) to (E.l) to compute r' (the red component value for the frame 
« next to r), we have 

W r' = (1-f) * SR + 1' * TR (E.4) 
m = ( l-t-At) * SR + (t+At) * TR 

= (l-i) * SR + t * TR + At * (TR-SR) 
1SI =r + Ar 

C5 where from (E.2) 

5 Ar = At * (TR-SR) = (TR-SR) / (FR * S) 

involves only constants (so long as the frame rate is constant) and thus can be pre- 
computed as a uniform increment only once in advance before the morph process 
20 starts. (E.4) states that the texel components can be interpolated through 

incremental addition (i.e., repeatedly adding or subtracting the same uniform 
constant value over and over again), including only one addition (subtraction) 
operation. See Figure 5. 

Notice that from (E. 1 ) we have 
25 r = SRUo 
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This gives the initial condition of equation (E.4). 

With this in mind, when given a source and target, the preferred embodiment 
divides the morph procedure into two phases: 

Morphine preparation (Figure 3, block 108) is done only once per 
5 source/target change. This is where the morph parameters (initial and incremental 
values for each texel) are computed. The following is example pseudo-code for 
such a computation: 

number OfFrames = frameRate * numberOfSeconds ; 
for(each texel in each texture tile) { 
10 redDlt[k] = (targetRedfkJ - sourceRedjk]) / number OfFrames; 

f , grnDltfkJ = (targetGrnfkJ - sourceGrnfkJ) / number OfFrames; 

J! bluDlt[k] = (targetBlufkJ - sourceBlu[kJ) / numberOfFrames; 

=1 alpDltfkJ = (target 'AlpfkJ - sourceAlpfkJ) / numberOfFrames; 

Lj newRedfk] — sourceRedfkJ; 

15fll newGrn[k] = sourceGrnfkJ; 

j2 newBlufk] = sourceBlufkJ; 

!" newAlpfkJ = sourceAlpfkJ; 

I ^ 

W Morphine process (Figure 3, block 1 1 0) is performed each iteration to change 
20iJ the value of color components for each texel when the morphing is in progress. In 
the preferred embodiment, only addition operations are used in this step. The 
following is example pseudo-code: 
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for (each texel in each texture tile) { 
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newRedfkJ += redDltfkJ; 
newGrnfkJ += grnDltfkJ; 
newBlufkJ += BluDltfkJ; 
new Alp [kj += AlpDltfkJ; 



unsigned char *texel = &textureBufferfkJ; 
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texel[RED] = newRedfkJ; 
texel [GRN] = newGrnfkJ; 
texel [BLU] = newBlufkJ; 
texelfALPJ = newAlpfkJ; 



A problem with the example morphing procedure described above relates to 



its use of integer addition. In order to preserve the accuracy, incremental and new 
O values (i.e. redDlt[], newRed[], etc.) should be floating point numbers. However, 
15- the 32-bit RGBA texture format defines components (i.e. texel[RED], texel[GRN], 

'% J: 

i\I texel[BLU] and texel[ALP]) to be 8-bit integers. Thus the last four assignment 
if! statements in the loop body above imply costly data type conversions. Hence, use 
-s of integer arithmetic to eliminate floating-point conversions for each incremental 
u. interpolation can (depending on the particular platform) significantly speed up the 
2@a morphing calculations, but may also result in a loss of accuracy as compared to 
□ the use of floating point arithmetic — since the intermediate morph values will be 
only integer approximations of the actual value, that would be obtained using 
floating point interpolation techniques. See Figure 5 A. To eliminate this hidden 
cost, the preferred embodiment uses a non-uniform integer correction factor -- i.e, 
25 it adds an additional integer correction factor (e.g., +1 or - 1) during some but not 
all morphing steps -- with a frame counter selecting when the correction factor 
should be added. 

When preparing morph parameters, the preferred embodiment separates the 
integer part and decimal part of the color delta values (see Figure 5B), and 
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computes the number of frames (i.e. redCnt[]) required for the decimal (fractional) 

part to add up to 1. For instance, if the decimal part of the delta value is 0.2, then 

the value of its frame counter should be 5. The following is example pseudo-code: 

forfeach texel in each texture tile) { 
5 delta = (targetRed[k] — sourceRed[k]) / numberOfFrames; 

redlnt[k] = floor(delta); 
decimal — delta - redlnt[k]; 
redCnt[k] = (L0 / decimal) + 0.5; 

10 //do the same to green, blue and alpha components; 

} 

When morphing texels, the preferred embodiment adds the integer part of an 
1 5 incremental value to a texel component in each iteration — and adds an extra 1 to 
~3 the value only when the number of iterations is a multiple of N, where N is 
Ipjj specified by its frame counter . See Figure 5. Such further incrementing by a non- 
j3 uniform amount corrects for approximation errors. Notice that all arithmetic 
p operations in the iteration involve only 8-bit integers. The following is example 
jpyj pseudo-code: 

if 5 // compute the multiples of current frame numbers. 

2£Q for(i—l; i< numberOfFrames; { 

frames [i] = (currentFrameYoi)? 0: 1; 

} 

currentFrame++; 

II morph texels 

25 for (each texel in each texture tile) { 

TEXEL TYPE *texel = &textureBuffer[k]; 

texel [RED] + = (frames [redCnt[k]])? (redlnt[k]+ 1): redlnt[k]; 
texelfGRNJ += (frames fgrnCntfkJJ)? (grnlnt[k]+ 1): grnlntfkj; 
texelfBLUJ += (frames [bluCnt[k]])? (blulnt[k]+ 1): blulntfkj; 
30 texel [ALP] += (frames [alpCnt[k]])? (alplnt[k]+ J J: alplnt[k]; 

} 
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The use of frame counters provides significant improvement in calculation 
speed, but also introduces a potential inaccuracy. Since it is not guaranteed that 
the decimal part of an incremental value can always be added up to exactly 1.0, 
the procedure is prone to "over-run" or "under-run" in certain circumstances, 
5 depending on how the value of a frame counter is calculated. For example, when 
approaching the end of morphing procedure, the texel values of an intermediate 
morph object may exceed that of the target object and create disturbing artifacts. 

To overcome this over-run problem, the preferred embodiment carefully 
chooses frame counters values so they never lead to an "over-run" situation. In 

1H| one simple illustration, the frame counter values are rounded down instead of up 
to ensure that the incremental interpolation process yields texel values that do not 

}S exceed the values they would take on if floating point arithmetic were used.. 

-J y To solve the resulting "under-run" situation, the texel values of the 

intermediate morph object is "snapped" to that of the target object by using a 
*K floating-point operation at the last increment — making the now fully morphed 
^ texel values become precisely equal to the target object texel values. See Figure 
5D. The results provided by the preferred embodiment become an approximation 
to those supplied by the heuristic solution after this step. 

Interlace morphing: 

!0 To further speed up the morphing process, the preferred embodiment defines 

INTERLACE to be a positive constant integer. When preparing the morph 
parameters, the preferred embodiment multiplies the integer parts of incremental 
values of components by this constant. When morphing textures, the preferred 
embodiment updates the values of texels at a regular intervals specified by 
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INTERLACE. For example, if INTERLACE=3 , then the preferred embodiment 

modifies texels 0, 3, 6, ... in the first iteration, modifies texels 1, 4, 7, ... in the 

second, do 2, 5, 8, ... in the next, and so forth. Here is example pseudo-code: 

for(i=l; KnumOfFrames; i++) { 
5 frames [i] = (currentFrame%i)? 0: 1; 

} 

for(k=interlace; k< TOTAL JTEXELS; k+ INTERLACE) { 

TEXELTYPE *texel = &textureBujfer[k]; 
10 texelfREDJ += (frames [redCnt[k]])? (redlnt[k]+ INTERLACE): redlntfkj: 

texelfGRNJ += (frames [grnCntfk]])? (grnlnt[k]+ INTERLACE) : grnlntfkj; 
texel[BLU] += (frames [bluCnt[k]])? (blulnt[k]+ INTERLACE): blulntfkj; 
texelfALPJ += (frames [alpCnt[k]])? (alplnt[k]+ INTERLACE): alplntfkj; 

q } 

lj£ interlace = (++ interlace) % INTERLACE; 

kj if (/interlace) currentFrame++; 

i — 

I J Figure 6 shows this example interlacing graphically, with one subset of texels 
= = 600a being incrementally interpolated every first of three successive frame times, 
20^ a second subset of texels 600b being updated every second of three successive 
£8 frame times, and a third subset of texels 600c being updated every third one of 
£1 three successive frame times. The Figure 6 interlacing morphs all texels every 
three frames, but only needs to morph 1/3 of the texels each frame - thus 
significantly reducing computational load. Interlace factors other than 3 (e.g., 2, 
25 4, etc.) can be used. 

Use of Background low-priority thread: 

Although the actually morphing procedure described above may run at a 
satisfactory speed, the procedure of preparing the morph parameters (i.e. 
incremental values and frame counters) is still computationally expensive.^ In some 
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circumstances, depending on the number of texels in texture tiles to be 
interpolated, it can introduce noticeable delays. To avoid this visual anomaly, the 
morph parameter preparation stage can be sprouted as a task with a lower priority 
running at the background. In the preferred embodiment, the morphing procedure 
5 starts only after receiving a signal from this background task upon its completion. 
This effectively eliminates the frame rate interruptions. 

Example Overall Texture Morphing Process 

Figure 7 is a flowchart of example run-time steps performed by the 
preferred embodiment of this invention. In the preferred embodiment, the process 
ljh 300 shown in Figure 7 is performed based on software instructions stored within 
% % cartridge 56. In this example, the Figure 7 morph process 300 begins in response 

m to user commands inputted through controls 54 and/or other code stored within 

in 

Iq cartridge 56 (block 306). Such an event causes a main thread 302 to begin 
o executing. Main thread, in turn, dynamically sprouts a background thread 304 
lgj (block 308) to perform certain computationally intensive tasks in advance of a 
£§ real-time morphing phase of the process. For example, background thread 304 
(which may be passed the source and target texture maps as well as parameters 
relating to a constant frame rate and the duration of morphing) computes certain 
initial and incremental morph parameter values for each texel component within 
20 the texture map to be morphed (block 310). In this example process 300, for each 
texel, background thread 304 computes an incremental integer and a frame counter 
value, multiplies the incremental, value by an interlace factor, and checks to make 
sure there are no overruns (block 310). 

Meanwhile, main thread 302 performs other computational duties (block 
25 312) and waits until background thread 304 is finished calculating the morph 
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parameters (decision block 3 14). Once background thread 304 is ready and has 
completed its calculation tasks ("yes" exit to decision block 3 14), main thread 302 
repetitively performs a morph processing loop comprising blocks 3 16-322. 

Within this processing loop (which may be performed each imaging frame, 
5 i.e., thirty times per second), main thread 302 interpolates each texel component 
within the texture map by adding the uniform incremental value for each 
component (as conditioned on an interlace factor), and may add a non-uniform 
value (e.g\, plus or minus one) in certain frames to compensate for approximation 
errors resulting from the integer arithmetic (block 318). An interlace counter is 
10 _ incremented to keep track of the interlacing factor vis a vis the current frame, and 
w the interlacing factor may be used to select which subset of texels to interpolate 
^-i during a given frame (block 322). This same calculation may be repeated for each 
iJl frame until the last morphed framed approaching the target texture (as tested for 
£5 by decision block 320). Upon reaching the last morphed frame ("yes" exit to 
15i3 decision block 320), process 300 "snaps" the texel component values to the actual 
rU target texture values (block 324) — thus avoiding noticeable image artifacts 
C 3 resulting from the integer approximation calculations performed by block 3 1 8). 

While the invention has been described in connection with what is presently 
considered to be the most practical and preferred embodiment, it is to be 
20 understood that the invention is not to be limited to the disclosed embodiment. 
For example, although the invention has been described in the context of a 3D 
texture morphing system, it can also find utility in the context of 2D image 
morphing, warping and/or blending. The invention is intended to cover various 
modifications and equivalent arrangements included within the scope of the 
25 appended claims. 
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